While less well-known than flowcharting techniques used for developing computer software, flowchart methods have also been used for designing electronic hardware systems.
Tredennick, for example, has described a "flowchart method" for designing the central processing unit (CPU) of a computer system (IEEE, December, 1981, pages 87-102).
Tredennick describes a procedure whereby a "principal of operation" definition for a computer processor is used to iteratively develop a corresponding hardware flowchart. The flowchart serves as a bridge between the English-language written technical definition of the processor and the people responsible for the final integrated circuit processor design.
The objective of Tredennick's procedure is to develop a flowchart that represents processor operation as the flow of simple processor actions or state changes, that is, a compact formal description of what the processor does. Tredennick's finalized flowchart specifies exactly how commands from the processor's instruction set are carried out by the processor's execution unit hardware.
More specifically, Tredennick's flowchart methodology begins with the development of trial the processor's instruction format and register set and a summary of those processor instructions applicable only to the execution unit. This "technical product definition" is used to generate a first iteration block diagram of the execution unit. This is done by first adopting a "register transfer" notation. Each statement of this notation defines a "task" that consists of transferring data from an identified source register within the processor's register set to an identified destination register via an identified bus.
The flow of execution unit states is depicted by boxes, one box for each state. Each execution unit state box contains one or more tasks. An execution unit "sequence" is defined as a succession of states.
First, a so-called "level one" flowchart, consisting of a full sequence of execution unit states, is defined for the execution unit. Then each task of each state is categorized as either an operational task or a housekeeping task. Operational tasks are transfers required to perform the instruction; operational tasks are transfers that must occur in a specific order and may be unique to a particular operation. Housekeeping tasks, such as incrementing the processor's program counter and fetching the next instruction, must also be performed for every instruction.
After the "level one" flowchart for the execution unit has been developed, housekeeping tasks are merged with operational tasks wherever possible to provide an optimized "level two" flowchart for the execution unit. This "level two" flowchart is used to modify the first version of the execution unit block diagram. This iterative process of flowchart generation and block diagram modification continues until a satisfactory execution unit block diagram is established.
The general procedure utilized to establish the execution unit block diagram is then applied broadly to generate a "level one" flowchart for the processor's controller section using the processor's entire instruction set.
Again, after developing the "level one" flowchart for the controller, housekeeping tasks are merged into operational tasks without, if possible, increasing the number of states in the operational task sequence. Descriptive information regarding the nature of a particular task is then added to the states identified in the "level two" processor flowchart.
After a minimization step, in which duplicate states are eliminated, the minimized "level two" processor flowchart is used to develop a processor design. The progression from the "level two" flowchart may be either to a microcoded version or to a combinational logic version of the processor.
The problem with the Tredennick flowchart methodology is that it is directed to system level applications, not to integrated circuits.
Another example of a hardware flowcharting technique is provided by the Daisy Computer Systems Hardware Compiler. The Hardware Compiler is a set of software programs that converts a high level logic description, such as a flow chart or text file, into a truth table.
The preliminary documentation for the Daisy
Hardware Compiler (Nov. 0, 1986) describes a procedure that begins with development of a high level logic description in the form of a finite state machine chart. A finite state machine is a device in which the logic state of the device changes at every clock cycle based on the current state and the inputs to the state machine.
The drawing description of the finite state
machine is consistent with the Mealy model and uses Christopher Clare's method of chart representation. First, an algorithmic state machine (ASM) chart is created. Each possible state and the transitions from state to state are diagrammed using three types of boxes: state boxes, decision boxes and conditional output boxes. After the components of the ASM chart have been assembled, parameters are assigned to each box and the associated information is linked with the boxes in a side file. Next, a finite state machine compiler translates the flow chart netlist, which consists of the side files associated with the ASM chart, to a computer aided design (CAD) netlist, essentially a truth table of the desired logic. A minimizer program then reduces the number of product terms in the truth table by combining any terms that are the same and by expanding some terms to cover others.
The minimized truth table generated by the Hardware Compiler may then be processed by conventional CAD tools to generate a circuit implementation.
The problem with the Hardware Compiler "flowchart" procedure is that it can be applied only to so-called single-phase of "edge-triggered" logic designs.